Many organisations are involved in the generation of documents. A law firm is an example of one such organisation. One of the main activities of a law firm is the drafting of legal documents such as agreements and contracts on behalf of its clients. Such a client may be engaged in a transaction of some kind, which may be very complex. A lawyer or team of lawyers at the firm can be tasked with the drafting of documents to support that transaction. Such documents are notoriously lengthy and complex, and moreover a high degree of importance is typically attached to the accuracy of the content of such documents. It is accordingly desirable to generate such documents in an efficient and accurate manner.
A number of document automation systems exist. Such systems typically elicit data from a system user for use in the generation of a document. Using the above example, data about a particular transaction may be elicited from lawyers engaged in the transaction project, and may be employed by such existing document automation systems to generate drafts of the requisite documents. Existing document automation systems typically allow users to modify the input data or to add new data, thereby modifying the generated documents.
Existing document automation systems use rules to generate documents based on the input data. In general, data may interact with such rules to form the content of a generated document. There are several ways in which a piece of data may affect the content of a generated document. For example, a piece of data may itself be expressed in the generated document. Alternatively, a section of the generated document may be inserted therein on condition that a piece of data has a certain value.
For illustrative purposes, consider the following two simple examples of transaction data: (a) the name of the party who is acting as the buyer; and (b) the information as to whether that party is a natural person or a legal person (e.g. a company).
With regard to example (a), there may be several places in a generated document where the name of the buyer will be expressed. For example (supposing that ‘Trustthorpe Ltd’ is the name of the buyer), the generated document may contain the clause “17.2 Trustthorpe Ltd shall pay all present and future stamp, documentary and other like duties and taxes (if any) to which this agreement may be subject or may give rise . . . ”. That is, the rules responsible for generating the document may ensure that whatever value the piece of data holding the buyer's name possesses, that value will appear in the locations that the rules specify.
With regard to example (b), whether a party is a real person or a company can affect which clauses are included in a generated document. For instance, the generated document may be an agreement that has an execution clause at which the party concerned should sign the agreement. The form of such an execution clause will normally be different in the case where the party is a company (legal person) from the case where the party is a real person (natural person). In order to provide the right kind of clause in the appropriate circumstances, the rules responsible for generating the document may have an “if . . . then . . . ” form, such that the rules will effectively provide that “if” the buyer is a company, “then” a particular clause should be used, however “if” the buyer is a real person, “then” a different clause should be used.
There are other ways in which existing document automation systems use data in combination with rules to control the content of generated documents. The most important and common of these is where a data structure is a collection of similar pieces of data and, when the rules are written, it is not known how many items the collection contains.
In such cases, the rules followed by the document generation system may instruct the generation process to insert something once for each member of the collection, however many members that may be. The process of doing something once for each member of a collection is known as iteration.
For example, suppose that the collection is of the names of the different parties to an agreement; the rules may instruct the generation process to express each member of the collection, thus creating a list of parties.
In more complex cases, what's iterated might involve ‘if . . . then . . . ’ rules. The ‘if . . . then . . . ’ example above concerns the creation of different forms of execution clause, and clearly one use of a more complex iteration would be to create, for each party to an agreement, an appropriate style of execution clause for that party. Here the iteration rule would specify that the ‘if . . . then . . . ’ execution clause rule is to be executed for each party.
US 2006/0036612 discloses a document automation system that includes an assembler for generating an instance document on the basis of a source document and one or more logic-source documents referenced by the source document. The source document and logic-source documents are XML documents including at least one XML processing instruction. The source document and logic-source documents are valid with respect to XML schema. The system generates an instance document in HTML, PDF or RTF format by resolving variables in the source document and/or logic sources using one or more data sources.
GB 2405729 discloses a document generation system that generates a customised document using content elements selected by rules operating on input information including transaction values. The system associates further rules with the transaction values and evaluates the further rules to produce an indication of the relevance of the presence or absence of the transaction values in a fully or partially customised generated document. The effect of the transaction values is represented by means of a mark-up.